Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Soft deprecate webrick and add some details as to why. #23

Merged
merged 4 commits into from
Nov 2, 2024

Conversation

ioquatix
Copy link
Member

@ioquatix ioquatix commented Nov 2, 2024

@jeremyevans I have copied your advice from #12 (comment) and moved webrick to a development dependency.

Fixes #12.

@ioquatix ioquatix requested a review from tenderlove November 2, 2024 00:54
@ioquatix ioquatix force-pushed the soft-deprecation-webrick branch 2 times, most recently from c837e1e to d5dc856 Compare November 2, 2024 00:57
Copy link
Contributor

@jeremyevans jeremyevans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Thank you for working on this.

readme.md Outdated Show resolved Hide resolved
@ioquatix ioquatix force-pushed the soft-deprecation-webrick branch from 9771b55 to d5d46c5 Compare November 2, 2024 02:33
@ioquatix ioquatix merged commit be54595 into main Nov 2, 2024
38 checks passed
@ioquatix ioquatix deleted the soft-deprecation-webrick branch November 2, 2024 02:50
myronmarston added a commit to block/elasticgraph that referenced this pull request Nov 4, 2024
Rackup 2.2 no longer depends on `webrick`, and our usage of `rackup` fails
if we don't add a dependency on `webrick`. For details on the `rackup`
change, see:

rack/rackup#23

Note that the `rackup` maintainers recommend using `falcon` or `puma`
instead of `webrick`. However, `falcon` and `puma` are heavier weight.
`falcon` has lots of runtime dependencies and `puma` depends on `nio4r`
which has native code. As a result, it's more likely to hit installation
issues for ElasticGraph users than `webrick`. So for now we are sticking
with `webrick` but I'm open to changing this in the future.
myronmarston added a commit to block/elasticgraph that referenced this pull request Nov 4, 2024
Rackup 2.2 no longer depends on `webrick`, and our usage of `rackup` fails
if we don't add a dependency on `webrick`. For details on the `rackup`
change, see:

rack/rackup#23

Note that the `rackup` maintainers recommend using `falcon` or `puma`
instead of `webrick`. However, `falcon` and `puma` are heavier weight.
`falcon` has lots of runtime dependencies and `puma` depends on `nio4r`
which has native code. As a result, it's more likely to hit installation
issues for ElasticGraph users than `webrick`. So for now we are sticking
with `webrick` but I'm open to changing this in the future.
dentarg added a commit to dentarg/sinatra that referenced this pull request Nov 7, 2024
WEBrick is not recommended for production usage, and the rackup gem
dropped the dependency on it. [1], [2]

With these changes in mind, just recommend Puma as the web server, for
simplicity.

[1]: ruby/webrick@70b026c
[2]: rack/rackup#23
dentarg added a commit to sinatra/sinatra that referenced this pull request Nov 7, 2024
WEBrick is not recommended for production usage, and the rackup gem
dropped the dependency on it. [1], [2]

With these changes in mind, just recommend Puma as the web server, for
simplicity.

[1]: ruby/webrick@70b026c
[2]: rack/rackup#23
Earlopain added a commit to Earlopain/rackup that referenced this pull request Nov 8, 2024
Followup to rack#23

Even when users do add webrick to their gemfile, the handler is not available.
This means that they either need to do that themselves, or dependencies need to
be updated.
@jeremy
Copy link
Member

jeremy commented Nov 12, 2024

If rackup itself is soft-deprecated, how about leaving the webrick dep in place and unwinding the compatibility snafu?

Allow it to continue behaving just as it did before, and advise folks to move off Rackup instead.

If Rackup does carry on, make the webrick dep change in a major release (3.0).

@ioquatix
Copy link
Member Author

I don’t have a strong opinion about this except that some of the things that broke already looked kind of broken to me.

I don’t think we should encourage further usage of webrick either. So if we did what you suggest and users upgrade to 3, they would be in the same boat? In other words the best solution for people right now is to pin the version until downstream dependencies are fixed? Or just accelerate the deployment and release of those fixes?

ioquatix pushed a commit to Earlopain/rackup that referenced this pull request Nov 13, 2024
Followup to rack#23

Even when users do add webrick to their gemfile, the handler is not available.
This means that they either need to do that themselves, or dependencies need to
be updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

webrick dependency necessary?
3 participants